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1. INTRODUCTION AND BACKGROUND 



1.1 Introduction 



This specification defines the proposed ^^^^^^^ 
that will provide security services to "W^^JS being-processed using the 
postage postmark or indiciurn that wd ^ •^^^ Po$tal Service (USPS) is 
Information Based Indicium Program (IMP). The United > 
issuing this specification to obtain comments from its customers ana 

The TBTP is expected to support new methods of applying postage in addiuon ^ 
eventually in lieu of, the current ap proach, this specification to 
mechanically print indicia on maupiece^ J^.^ ^g), are P not expec ted to 

refer to the host computer system or the meter, as appropn<uc — 

differ ^enco^ 

1.2 Structure of This Specification 

This specification is organized into five sections and ^appendices. The following is an 
overview and general description of each section and appendix. 

. Section 1 - introduction and Background: This section gives readers a brief 

introduction to the PSD specification. 
. Section 2 - PSD Overview: This section presents an overview of PSD functions. 

^rtian 3 - PSD and D3D7 Functions: This section specifies the PSD core 

finance, indicium creation, and device audit functions. 

PSD Physical Requirements: This section documents the physical 
' rltntcfor the PSD It covers PSD contents, software, watchdog timer, 

%ZZS^£'a*+ key handling, and input/output recrements. 

. Section 5 - PSD Test Requirements: This section specifies the test 

requirements for the PSD. 

a- a Wn«t Svstem Security Requirements: This appendix addresses 
. Appendix A - Host System * ecur "* " «J developers of the 

host system security requirements that must be unaersiooa oy 

PSD. 

• Appendix B - List of Acronyms. 
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13 Interpretation of Requirements 

xh . m * m » present in *^JS^J^Z£2£ 

implementation purposes. 

PSD is designed to use such signature methods. 
14 Reference Documents and Resources 

The proposed reo—s and spoons inciuded in ,his documen, are supported * 
the primary resources: 

. USPS Domestic Mail Manual (DMM) September 1. 1995. 

n - v 1Q rFR p arts l n and 501 , Manufacture, 

• Federal Register, Part V, 39 CFR Parts i u » • 
Distribution, and Use of Postage Meters; Final Rule June 9, 

• Uniform Symbology Specification PDF4 1 7 July 1994. 

. Digital Signature Standard - HPS PUB 186 May 19, 1W4. 
. SecureHash Standard'- FIPSPUB 180-1 April 17,1995. 
. Security Requirements for Cryptographic Modules - FTPS PUB 140-1 11 
January 1994. 

. Cryptographic Module Validation Program Announcement July 17, 1995. 
. InformationBasedlndiciumProgramlndicium Specification June 13. 1996. 
. information Based Indicium Program System Specification, (to be issued). 
. PKCS#1RSA Encryption Standard version 1.5 November 1. 1993. 
. RFC 1321, The MD5 Message Digest Algorithm April 1992. 
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15 Patent and License Considerations 
such as licenses, to use the approach chosen. 
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2. POSTAL SECURITY DEVICE (PSD) OVERVIEW 

The Postal Security Device (PSD) provides security-critical functions for IBIP customers. 
The PSD will be a hardware component for use with either a computer-based or postage 
meter-based host system. Each PSD will be a unique security device. The PSD core 
security functions are cryptographic digital signature generation and verification, and he 
secure management of the registers that track the remaining amount of money available 
for indicium creation (descending register) and the total postage value used by this PSD 
(ascending register). To ensure the security of IBIP processes, certain core secunty 
functions, which are further described in Section 2. 1, must be performed by the PSD In 
order to securely perform these .functions, the PSD will be a tamper-resistant device that 
will contain an internal random number generator, various storage registers a date/time 
dSck, and other circuits necessary to perform these functions. The PSD will be compliant 
with FTPS 140-1 and will be validated through the National Institute of Standards and 
Technology (NIST) Computer Systems Laboratory's Cryptographic Module Validation 
Program. 

The PSD core security functions will support the implementation of the IBIP device 
authorization, finance, indicium creation, and device audit functions which are further 
described in Section 2.2. The PSD ensures that only authorized IBIP customers are able 
to apply a valid indicium to a mailpiece. Figure 2-1 illustrates the role that the PSD plays 
in the creation of indicia. 

Figure 2-1. PSD Role in D3IP Indicia Creation 
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2.1 Core PSD Security Functions 
Zl.l PSD Initialization 

PSD initialization is the process of loading the unique device identifier ^ 
V 509 certificate into the PSD. (The initialization information also must be entered in the 
m^eSSS^S^e.) The PSD must be initialized before it can be authonzed for 
customer use. 

ZJ.2 PSD Digital Signature Function 

A digital signature is a process that enables the recipient of a signed message to verify that 
fhe contentfof the message have not been modified. The PSD wul generate a digital 
sLature for each indicium. It also will generate a digital signature to ensure that the 
dSce audit information has not been modified. The PSD will be required to venfy the 
digital signature of the USPS for IBTP finance functions. 

2.1.3 PSD Register Management Function 

Register management refers to the ability of the PSD to securely ^^P"^ 1 ^^^" 8 
and descending registers. The PSD will use register management to support the ffilP 
finance, indicium creation, and device audit functions as discussed m Section 3.2. 

2.1.4 PSD Functional Allocation 

The PSD core security functions will support the implementation of the IBIP 
requirements. The matrix of PSD security functions and IBIP functions is provided m 
Table 2.1-1. 



Table 2.1-1. PSD Security Functions and IBIP Functions Matrix 



PSD Security Functions 




Digital Signature 
Register Management 



IBIP Device 
Authorization 



IBIP Financial 
Functions 



IBIP Indicium 
Creation 



2.2 IBIP Functions 

2. 2. I IBIP Device Authorization 

The IBIP authorization process ensures that only an authorized device can support the 
creation of a valid indicium. The vendor will authorize a PSD for use by z £*afc 
licensed customer. Once a PSD is authorized, the finance functions must be performed 
before the first indicium is created. 
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2.2.2 IMP Finance 

T „e B IP finance function — « ^^sSenSs with the 
^^^^ 

^ fcr postage value download. has been 

bC T?? ^^J^Zt^^^ A- by .he added 
venfied, the PSD will increase we va,u ^„ . d a status message 

register and the current value of the ascending regtster. 

2.2.3 IBIP Indicium Creation 

The PSD and the host system will jointly perform ^^S^^ep^put 

for selected fields in the indicium. 

2.2.4 IBIP Device Audit 

The device audit ftinction allows the ^^^^^ output I" 
such use, the PSD will create an ^^^^^Mog timer function, 
host system for transfer to the USPS. The PSD ^>P ro adequately audited by 

This function will preclude indicia creation if the PSD has not Deen 4 

the USPS. 
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3. PSD FUNCTIONAL REQUIREMENTS 

Functional requirements for the PSD are specified in two subsections below^ Section 3.1 
identifies core PSD functional requirements. Section 3.2 identifies how the core PSD 
functions are to be applied to satisfy overall IBIP requirements. 

3.1 Core PSD Functional Requirements 

This section presents requirements for the core PSD functions that will be applied in 
JSTSSKn. implement security services for the IBIP functions presented ,„ 
Section 3 2 In the event that vendors wish to extend the PSD to applications beyond 
IBIP, the core functions also could be used to support these applications. 

3.1.1 PSD Digital Signature Functions 

The PSD may implement either DSA, RSA, or another vendor su 88 ested r a "^SPS 
approved method for the creation and verification of digital JVf™ If DSA or RSA 
are used the PSD must adhere to the requirements specified in Section 3.11. 1 for DbA or 
Section 3.1.1.2 for RSA and the appropriate 8°^™^°.^^ in 
Requirements for other approved digital signature methods, if any, will be documented m 
a future version of this specification. 
3.1.1.1 Digital Signature Algorithm Requirements 

If DSA is chosen the PSD shall use the DSA, as specified in FIPS PUB 186 to implement 
generation and verification functions, using the standard DSA parameters 
that are defined in FTPS PUB 186. These functions process input messages in the formats 
soecified in Section 3.2. Figure 3.1-1 illustrates the generic signature generation and 
verification processes. Applications of these processes to satisfy IBIP requirements are 
defined in Section 3.2. 

The following sections, Section 3.1.1.1.1 and Section 3.1 1.1.2. detail 

parameters for the use of DSA. A PSD must adhere to the requirements addressed m 

these sections only if it implements DSA for IBIP. 

3.1.1.1.1 PSD Digital Signature Algorithm Parameters 

Using the default, standard parameters specified in FIPS PUB 186 the PSD shall obtain or 
genefau!^ appropriate, the DSA parameters listed in Table 3.1-1 for s,gnature 
generation, and Table 3 .1-2 for signature verification. 
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Figure 3.1-1. Digital Signature Gencrotionond Verification ' 
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Table 3.1-1. DSA Parameters Tor Signature Generation 



|| Parameter 


Soorce 


PSD Storage 


Comments . j 


P 


Loaded into the PSD during device 
authorization 


Stored in nonvolatile 
memory until replaced or 
erased 


DSA standard parameter common 
for all PSDs 


q 


Loaded into the PSD during device 
authorization 


Stored in nonvolatile 
memory until replaced or 
erased 


DSA standard parameter common 
for all PSDs 


g 


Loaded into the PSD during device 
authorization 


Stored in nonvolatile 
memory until replaced or 
erased 


DSA standard parameter common 
for all PSDs 


X 


Generated by the PSD or loaded from 
externa] source 


Stored in nonvolatile 
memory until replaced or 
erased 


PSD private key 


y 


Calculated by the PSD if the x parameter is 
internally generated and output to host 
svstem 


Not stored in the PSD 


PSD public key 


M 


Message created by the PSD based on host 
system inputs and internal register contents 


Stored in the PSD only for 
the duration of DSA 
signature generation 


Output to host system by the PSD 


k 


Generated by the PSD 


Used for a single signature 
erased after use 


A new random value must be 
generated for each digital signature 


r 


Calculated by the PSD during the DSA sign 
operation 


Result of DSA signature 
generation; erased after us 


Output to host system by the PSD 


$ 


Calculated by the PSD during the DSA sign [Result of DSA signature 
operation (generation: erased after us 


Output to host system by the PSD 
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3.1.1.1.2 PSD Secure Hash Algorithm 



In accordance with HPS PUB 186, the Secure Hash Algorithm (SHA-1), as specified in 
the Secure Hash Standard, FIPS PUB 1 80-1, shall be used to create a 160-bit message 
digest that is used in the creation of the digital signature- 
Table 3.1-2. DSA Parameters For Signature Verification 



1 Parameter 


Source 


PSD Storage 


Comments — - j 


p 


Loaded into the PSD during device 
authorization 


Stored in nonvolatile 
memory until replaced or 
erased 


DSA standard parameter common 
for all PSDs 

(Same as p parameter for signature 
generation) 


q 


Loaded into the PSD during device 
authorization 


Stored in nonvolatile 
memory until replaced or 
erased 


DSA standard parameter common 
for all PSDs (Same as q parameter 
for signature generation) 


£ 


Loaded into the PSD during device 
authorization 


Stored in nonvolaule 
memory until replaced or 
erased 


DSA standard parameter common 
for all PSDs 

[Same as g parameter for signature 
generation) 


y 


Loaded into the PSD from the host system 


Stcrcx? in nonvolatile 
memory until replaced or 
erased 


Public key of message originator 


rvT 


Message as received from message originator 


Stored in PSD only for 
duration of DSA signature 
verification 


Input from the host system io the 
PSD 


r 


r value received from message originator 


Stored in PSD ordy for 
duration of DSA signature 
verification 


Input from the host system to the 
PSD 


s" 


s value received from message originator 


Stored in PSD only for 
duration of DSA signature 
verification 


Input from the host system to the w 
PSD 


w, ul, u2. v 


Generated by the PSD during signature 
verification process 


Stored in PSD only for 
duration of DSA signature 
verification 


Die signature is verified if v~r'; 
PSD actions upon verification (or 
failure of verification) are specific 
in Section 3.2 



3.1.1.2 RSA Requirements 

If RSA is chosen, the PSD shall use RSA as specified in PKCS Ul section 10, to 
implement digital signature generation and verification functions, using the standard RSA 
parameters that are defined in PKCS #1 : RSA Encryption Standard. These functions 
process input messages in the formats that are specified in Section 3.2. Figure 3.1-2 
illustrates the generic signature generation and verification processes. Applications of 
these processes to satisfy IBIP requirements are defined in Section 3.2. 
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The following sections, Section 3.1.1.2.1 and Section. M. 1.2 2; detail jtfjGjtfmeriUdrid. • 
parameters for the use of RSA. A PSD must adhere to the requirements addressed in 
these sections only if it implements RSA for IMP. 



Figure 3.1*2. RSA Digital Signature Generation and Verification 
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3.1.1.2,1 PSD RSA Digital Signature Parameters 

If RSA is used, the PSD shall generate the appropriate parameters, listed in Table 3.1-3 
for RSA signature generation and Table 3.1-4 for RSA signature verification. 



Table 3.1-3. RSA Parameters for Signature Generation 



j Parameter 


Snumr 


PSD Storage 


Comments I 


P 


Generated by the PSD during device 
authorization 


N/A 


Needed to calculate the PSD's 
modulus n 


q 


Generated by the PSD during device 
authorization 


N/A 


Needed to calculate the PSD's 
modulus n 


n 


Modulus for the PSD, calculated during 
authorization 


Stored in nonvolatile 
memory until replaced or 
erased 


n=pq, stored as pan of the PSD 's 
public key 


e 


Generated by the PSD during device 
authorization 


Stored in nonvolatile 
memory until replaced or 
erased 


PSD's private key 


d 


IBIP established parameter 


Stored in nonvolatile 
memory until replaced or 
erased 


RSA exponential value used, in the 
signature verification process 


S 


Generated during the RSA signature 
generation process 


Stored in PSD only for 
duration of RSA signature 
generation 


Result of the RSA signature 
generation that is output to the hos 
svstem 
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Table 3.1-4. RSA Parameters for' Signature Verification 



|l Paramctci 


Source 


PSD Storage 


. Comments - f 


n 


Certificate of the signer 


Stored in nonvolatile 
memory until replaced or 
:rased 


Pan of the signer's public key 


d 


EBIP established parameter 


Stored in nonvolatile 
memory until replaced or 
erased 




M 


Message generated by ihe sender 


Stored in PSD onJy for 
duration of RSA signature 
verification 


n=pq, stored as pan of the PSD's 
public key 


s 


vj^jt^idicu uy uic message originator during 
message creation 


Stored in PSD only for 
duration of DSA signature 
verification 




MD 


Message digest from the signature of the 
message 


Stored in PSD only for 
duration of DSA signature 
verification 


Input from the host system to the 
PSD 


MD' 


Generated using the received message during 
he RSA signature generation process 


Stored in PSD only for 
Juration of RSA signature 
verification 


EIS A signature is verified if 
vTD'-MD 



3.1.1.2.2 RSA Message Digest 

The MD5 Message Digest Algorithm, as specified in RFC 1321, shall be used to create a 
128 bit message digest for use in the digital signature process. 

J. 1.2 PSD Register Management Functions 

The PSD shall store and increment ascending and descending registers in nonvolatile 
memory to support the BIP finance, indicium creation, and device audit functions as' 
d.scussed in Section 3.2. The management of these registers is specified in this section. 

3.1.2.1 PSD Register Formats 

Each register will represent a monetary value. The monetary values shall be measured in 
1/10 of one cent increments. The ascending register shall consist of twelve numeric digits 
The descending register shall consist of nine numeric digits. Therefore, the register values 
shall be interpreted as follows: 

• Ascending Register: SXXX.XXX.XXX. XXX 

• Descending Register: SXXX.XXX.XXX 

The ascending register will support any value up to SI billion and the descending register 
any value up to SI million. (The maximum dollar value that may be loaded into the 
descending register will be established by USPS policy.) 
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3.1.2.2 PSD Register Operations . 

When the PSD receives a postage value download message resulting from the IBIP 
finance function and that message has been validated as discussed in Section 3.2, the PSD 
shall check for the replay of prior postage value download messages by comparing the old 
control total field in the postage value download message with the sum of the ascending 
and descending registers in the PSD. When the control total in the download message 
equals the sum of the values of the ascending and descending registers, the descending 
register value shall be increased by the amount of the postage value contained in the 
download message. If the control total in the download message does not equal the sum of 
the values in the ascending and descending registers, the PSD shall abort the download 
process and send an appropriate message to the host system. 

When the host system requests the creation of an indicium, the PSD shall perform several 
operations using the ascending and descending registers. First, the PSD shall compare the 
requested postage amount input from the host system with the allowable limits currently in 
effect. If the requested postage amount is greater than or equal to the minimum limit and 
less than or equal to the maximum limit, the PSD will proceed with its register 
management functions. The requested postage amount shall then be compared to the 
value contained in the descending register. When the descending register contains 
sufficient value, the register values shall change in accordance with Table 3.1-5. If an 
insufficient value remains in the descending register, the PSD shall return an appropriate 
message to the host system and abort the indicium creation function. 



Table 3.1-5, Ascending and Descending Register Operations 



IBIP Function 


Ascending Register Operation 


Dcsccndin;:l*c«itfcr Operation | 


Indicium Creation 


The value contained in the 
ascending register shall increase 
by the postage amount specified 
by the host svstem 


The value contained in the 
descending register shall 
decrease by the postage amount 
specified by the host system ! 


Finance 
(Upon receipt of postage value 
download message by the PSD) 


The value contained in the 
ascending register shall be 
unchanged by the finance 
function 


The value contained in the I 
descending register shall increase 
by the amount of postage value 1 
contained in a valid postage 
value download message f 



3,1.2.3 Register Integrity 

After completion of the initialization of the PSD, the PSD shall have no mechanism 
available to either the vendor or the customer to alter the value contained in the ascending 
register except as specified in Section 3.1.2.2. 

The PSD shall have no mechani sm to a lter the value contained in the descending register 
except as specified in Section 3.1-2*2.- 

Information Based indicia Program (IBIP) June 13 ' 1996 

PSD Specification: Draft Document 

3-6 



BNSOOCID: <XP 2137734A_J_> 



Upon request of the host system, the current value of the descending register shall 
output to the host system for display to the user. This function will allow the user to 
determine the remaining postage value contained in the PSD. The host system shall have 
no mechanism to alter the ascending and descending register values in the PSD, 

3.1.3 PSD Initialization 

The initialization of a PSD includes loading the vendor's public key and the PSD device 
ED. In addition, the PSD shall explicitly initialize all internal registers, counters, etc., to 
their intended initial values. 

The private key, which corresponds to the vendor's public key, will be used by the vendor 
to digitally sign selected information that is loaded into the PSD. At a minimum, the 
information to be signed shall include the PSD device ID (see section 3.1.3.2) and all IBIP 
device authorization information (see section 3.2.1). This key also may be used to sign 
other vendor-defined information that must be loaded into the PSD. The vendor shall 
define the specific format of the data to be signed for input into the PSD. 

If DS A or RSA are used, the PSD shall use the signature verification function specified in 
either the DSS and Section 3.1.1.1 or the RSA PKCS and section 3.1.1.2 to verify the 
authenticity of the information loaded into the PSD. If the verification process fails, the 
information shall be discarded without further processing and an appropriate error 
indication shall be returned to the host system. 

3.1.3.1 Load Vendor Public Key 

The PSD shall be loaded by the vendor with the vendor's X.509 certificate, which contains 
the vendor's public key. This key shall be placed in nonvolatile storage in the PSD. The 
PSD shall have a mechanism to preclude the reloading or erasure of this key unless a new 
vendor X.509 certificate is received signed Dy the UM'S. ~ 

3.1.3.2 Load PSD Device ID 

Each PSD shall be loaded with a unique device ID, which will be based on a 3 -digit 
vendor ID, a 3-digit model number, and an 8-digit PSD serial number. The USPS will 
assign the vendor ID. The USPS will assign the model numbers based on 
recommendations made by the vendor. The vendor shall assign a unique PSD serial 
number to each PSD during the manufacturing process. Any revisions to the PSD, 
including software upgrades to existing PSDs, shall result in a new 3-digit model number, 
making it necessary to load the new device ID into the PSD. 

3.1.3.3 PSD Register Initialization 

When the PSD is initialized by the PSD manufacturer, the values of both the ascending 
and descending registers shall be set to $000,000,000,000 and $000,000,000, respectively. 
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3.2 PSD Requirements to Implement IBEP Functional* Acquirements 

This section presents the requirements for the proper implementation of IBIP functions. 
Where appropriate, reference is made to the core PSD functional requirements presented 
in Section 3.1. 

5.2.7 IBIP Device Authorization Requirements 

During the IBIP customer authorization process, the vendor will tailor the PSD for a 
particular customer and fully enable it to perform IBIP functions. This tailoring process is 
referred to as "device authorization" in this specification. 

Prior to performing the device authorization functions, the PSD must have been initialized 
in accordance with Section 3 . 1 .4 of this specification. PSD device authorization shall 
include the steps identified in the following subsections. 

A vendor may reprogram a PSD with new device authorization information if the relevant 
customer authorization information changes (e.g., new address or device is re-issued with 
a new lease). The vendor must reprogram a PSD with the appropriate device authorization 
information if the PSD is issued to a different customer by the vendor. 

3.2.1.1 Digital Signature Algorithm (DSA) Parameter Loading 

If the PSD supports DSS, the PSD shall be loaded with the IBIP common DSA 
parameters (i.e., p, q, and g). The DSA parameters shall be stored in the appropriate 
nonvolatile memory location in the PSD. (These parameters must be obtained by the 
vendor from the IBIP certification authority in accordance with the IBIP system 
specification.) 

3.2.1.2 Private/Public Key Processing 

The PSD sliall internally generate its own private key upon command from the vendor. 
The PSD shall calculate its public key based on its private key in compliance with FIPS 
PUB 186. 

If the PSD implements the RSA algorithm, the PSD shall first generate its public key and 
then calculate its corresponding private key. The PSD shall output the public key to the 
vendor's host system. (The vendor will be responsible for passing the public key to the 
IBEP certification authority.) 

The PSD private key shall be stored in the appropriate nonvolatile memory location in the 
PSD. The X.509 Certificate, containing the PSD's public key, shall be loaded into and 
stored in the PSD and/or the host system. This implementation is vendor specific. 
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3.2.1.3 Customer Identification Loading ; ; \ 

The PSD shall be loaded with the customer license ID number and the 12-digit value to be 
placed in the originating address field in each indicium. 

3.2.1.4 USPS X.S09 Certificate Loading 

The PSD shall be loaded with the X.509 certificate of the USPS that is obtained from the 
IBIP certification authority. The PSD shall use the signature verification process that is 
specified in section 3.1.1 to validate that the USPS X.509 certificate was received without 
modification. The format of the USPS X.509 certificate is provided in the EBIP system 
specification. Subsequent to successful verification of this certificate, the public key that 
is contained in the certificate will be used to verify signatures on postage value download 
messages and other messages that are received from the USPS. 

3.2.1.5 Maximum/Minimum Postage Amount Loading 

The PSD shall be loaded with the maximum and minimum postage values that the PSD 
will be allowed to process. These USPS-determined values stipulate the allowable range 
of the postage amount that a PSD is authorized to apply to an indicium. Additionally, the 
PSD shall have a mechanism to permit the printing of zero postage as specified in the 
DMM. 

The PSD shall have a mechanism to update the maximum and minimum allowable postage 
range when the USPS changes postage rates. 

3.2.1.6 Watchdog Timer Reset Value 

The initial value of the watchdog timer shall be set by the vendor at authorization. The 
PSD shall be loaded with a value, which is measured in days, that will be used as the reset 
value of the watchdog timer. 

3.2.2 IBIP Finance Functions 

The fundamental role of the PSD in the implementation of the IBIP finance functions is to 
request, accept, and process postage value download messages in accordance with the 
IBIP system specification. The process is illustrated in Figure 3 .2-1 To support IBIP 
finance functions, messages originating from the PSD must be transferred to the IBIP 
infrastructure, and messages from the IBIP infrastructure must be transferred to the PSD 
The specific transfer mechanisms for these messages are beyond the scope of this 
specification and may vary. 

When a customer needs to add postage value to their PSD, the customer must have 
sufficient funds on deposit with the USPS. The customer will not be able to add postage 
value to the PSD until sufficient funds are on deposit. If necessary, the customer must 
execute a funds transfer to the USPS. 
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The PSD will initiate the postage value download process with an appropriate request 
message to the USPS IBIP infrastructure. As pan of the request message, the PSD will 
assign a unique 6-digit transaction ID number to the request. The transaction ED number 
will be used in the resulting postage value download, error, and status messages to 
associate those messages with the original request message. 

Upon receipt of the request message, the IBIP infrastructure will check for sufficient funds 
and compare the PSD-originated information with the corresponding information 
contained in the IBIP databases. Successful checks result in a Postage Value Download 
(PVD) message to the PSD, or if a check fails, a PVD error message. Once the PSD 
receives and processes its added postage value message, it will reply with a postage value 
download status message to indicate successful or failed processing to the IBIP 
infrastructure. Requirements for messages processed by the PSD are further specified in 
the subsections that follow. 

The PSD shall complete its role in the process by sending a device audit message, 
described in Section 3.2.4, to the IBIP infrastructure and resetting its watchdog timer. 
The PSD vendor shall define an approach to resolve failures during the postage download 
process. 



Figure 3.2-1. IBIP Finance Function Process 




3.2.2.1 Postage Value Download Request Message 

The PSD shall initiate the postage download process by creating a request message, as 
described in this section, and passing that message to the host system for transmission 1 
the IBIP infrastructure. 
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3,2.2.1.1 Postage Value Download Request Message Forma* 

The request message for download of postage value shall contain the fields, sizes, and 
formats that are indicated in Table 3.2-1. However, the size of the digital signature and 
the PSD X.509 certificate fields may vary if the vendor implements another USPS- 
approved digital signature approach. Each request message shall be assigned a unique 
transaction ID number by the PSD. The transaction ID number and the amount of 
requested additional postage value shall be stored in the PSD for comparison with the 
corresponding fields in the received postage value download message. 



Table 3.2-1. Postage Value Download Request Message Format 



Tield Name 


Size 


Comments 


Device ID/Tvpe 


7 bvtes 


The requesting PSD device ID/rvpe number 


I License ID 


5 bvtes 


The license ID associated with the requesting PSD 


J Transaction ID 


3 bytes 


A counter maintained internally by the PSD that is 
incremented with each postage value download request 


Requested Additional 
Postage Value 


5 bytes 


The requested additional postage value consists of nine 
numeric digits in a 5-byte field 


Ascending Register 


6 bytes 


Value of the ascending register 


Descending Register 


5 bytes 


Value of the descending register 


Message Creation 
Date/Time 


5 bytes 


Date and time that the message was created, in format 
YYMMDDHHMM 


Previous Added Postage 
Value 


5 bytes 


Added postage value amount from the most recent 
postage value download transaction | 


Previous Postage Value 
Download Date/Time 


5 bytes 


Date/time that the most recent postage value download 
transaction was processed 


Digital Signature 


PSA 

40 
bytes 


RSA 
128 
bytes 


The digital signature that will be used to verify that the 
message was not altered enroute to the USPS. For 
DSA, the first 20 bytes of this field will contain the r 
value and the last 20 bvtes will contain the s value. 


PSD X.509 Certificate 


PSA 
235 
bvtes 


RSA 
323 
bvtes 


The X.509 Certificate containing the public key 
necessary to verify the digital signature. 



3.2.2.1.2 Postage Value Download Request Message Signature Generation 

The digital signature for the postage value download request message shall be created by 
the PSD, as specified in Section 3. 1.1 of this specification. If DSA is implemented, the 
input message for the digital signature process is shown in Figure 3.2-2. If RSA is 
implemented, the input message for the digital signature process is shown in Figure 3.2-3. 
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Figure 3.2-2. Input for the Postage Value Download Request Signature Generation 

Using DSA 



Device ID/ 
Type 


License 
ID 


T ran action 
ID 


Ascending 
Rcgisur 


Requested 
Additional 
Postage Value 


Previous 
Added 
Postage Value 


Descending 
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Menage 

Creation 
DstcTimt 


Previous 
Poitagc Value 
Download 
Date /Tunc 


Message 
Pad 


T Bytes 


3 Bjrtt* 


1 ByU« 


IByui 


i Bywi 


S By** i 


5 Byus 


5 Bytes 


3Bvus 


It Bytts 




t 1 






i 




t 1 1 





Mm! 

Tff* 



NnI 

B« *'Mm 
»7*» •* 



• • *f Mm 
TmxtMl 



Mmi 

IttfUMl 

a«sitv«af 
Br** *f v«am 



ItrfMMT 

i«ttfkMi Br* 



a««tT«*Mt Bfw 



MM 

Sifti/Waal 

lpi.{Vtli* Br***/ 

•faiD«MMfo| M*M«* 

a««ia*f Cn«* 



Mm 

a«»ir««*i 

B««f Mm 
a«aJWwl 



a* «tfWwi Br*« •/ 
r«>i«i* v«h>« 



p««B*«r 

to A^mteM 
Wn» RM FOB 

ISO 1 



Note 

1 The contents of the Device ID/Type, License ID. Transaction ID Message Creation Date/Tone, and Previous Added Postage Vehje 
Date/Time will be binary representations of each numeric digit with two digits in each byte 



Figure 3.2-3. Input for the Postage Value Download Request Signature Generation 
Using RSA 
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ID 


Transaction 
ID 


Ascending 
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Date/Tune 


Previous 
Postage Value 
Download 
Date/Tine 


7 Byus 




J Bytts 
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NMl«iiT«et 
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1 The eontenu of the Device ID/Type. License ID. Tmuaetion ID Message Creation Date/Time, and Previous Added Postage Value 
Date/Time will be binary representations of each numeric digit with two digits in each byte. 
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3.2.2.2 Postage Value Download Message 



After the USPS IBIP infrastructure successfully checks for receipt of adequate funding 
from the PSD licensee and validates the audit data that is provided in the request message, 
it will prepare and return the additional postage value that was requested by the PSD in a 
postage value download message as described in this section. 

3.2.2.2.1 Postage Value Download Message Format 

The postage value download message will contain the fields, sizes, and formats indicated 
in Table 3.2-2. However, the size of the digital signature field may vary if the vendor 
implements another USPS-approved digital signature approach. 



Table 3:2-2. Postage Value Download Message Format 



| Field Name 


Size 


Comments - - - - - - 


Device ID/Type 


7 bytes 


The PSD shall only accept postage value messages 
containing the device ED/r>pe number of that PSD 


Transaction ID 


3 bytes 


The transaction ID from the postage value download 








request message 


Old Control Total 


6 bytes 


The old control total, consisting of 12 numeric digits in a 
6-byte field, is used to verify that the postage value 
download message has not previously been processed by 1 
the PSD 


Added Posxage Value 


5 bytes 


The added postage value consists of 9 numeric digits in a 
5-bvte field 


Digital Signature 


DSA 

40 
bytes 


RSA 
128 
bytes 


The digital signature will be used to verify that the 
message was not altered enroute to the PSD. For DSA, the j 
first 20 bytes of this Meld will contain the r' value and the 
last 20 bvtes will contain the s' value. | 



3.2.2.2.2 Postage Value Download Message Signature Validation 

Upon receipt of a postage value download message from the host system, the PSD shall 
format the data for signature verification. If the PSD uses DSA or RSA, the data shall be 
formatted as shown in either Figure 3.2-4 or Figure 3.2-5 for input into the signature 
verification process. If the PSD implements DSA, the PSD shall extract the r' and s' 
values for the signature verification process from the digital signature field in the received 
postage value download message. 

The PSDs implementing either DSA or RSA shall use the signature verification process 
defined in Section 3 .1.1 to verify that the message was received without modification. If 
the verification process fails, the message shall be discarded without further processing, 
and an appropriate error indication shall be returned to the host system. 
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Figure 3.2-4. Input Format for Postage Value Downlead Signature V e riftr?uion 
(Received message, M\ as defined in the DSS) 



Device ID/Type * 


Transaction ID 


Old Control Total 


Added Postage Value 


Message Pad 


7 Bytes 


3 Bytes 


6 Bytes 


5 Bytes 


43 Bytes 



Most 

Significant 
Bit of Most 
Significant 
Byte of Device 
IDType Field 



t t 



Most 

Significant 
Btt of Most 
Significant 
Byte of 
Transaction ID 
Field 



t t 



Most 

Significant 
Bit of Most 
Significant 
Byte of Old 
Control Total 
Field 



Most 

Significant 
Bit of Most 
Significant 
Byte of Added 
Postage Value 
Field 



t 



First B it of 
Message Pad 
In Accordance 
With FTPS PUB 
110-1 



1 The contents of the Device ID/Type. Transaction ID. Old Conlol Total and Added Postage Value fields will be binary representations 
of each numeric digit with two digits in each byte 



Figure 3.2-5. Input Format for Postage Value Download Signature Verification 

Using RSA _ 



Device ID/Type 


Transaction ID 


Old Control Tola! 


Added Postage Value 


7 Bytes 


3 Bytes 


6 Bytes 


5 Bytes 



t 



Most 

Significant 
Bit of Most 
Significant 
Byte of Device 
ID/Type Field 



t 



Most 

Significant 
Bit of Most 
Significant 
Byte of 
Transaction ID 
Field 



t 



Most 

Significant 
Bit of Most 
Significant 
Byte of Old 
Control Tout 
Field 



t 



Most 

Significant 
Bit of Most 
Significant 
Byte of Added 
Postage Value 
Field 



1 The contents of the Device CVType. Transaction ID. Old Contol Total and Added Postage V.lue fields will be binary representations 
of each numeric digit with two digits m each byte 



3.2.2.2.3 Postage Value Download Message Processing 

After the signature verification process has been completed, the PSD shall compare the 
received transaction ID number with the pending request message transaction ID number. 
If these match, the PSD shall process the message in accordance with Section 3. 1.2.2 of 
this specification. If the transaction ID numbers do not match or if there was no pending 
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request message, the PSD shall abort the processing o T 'the download message an J create 
an appropriate status message in accordance with Section 3.2.2.3 of this specification. 

3.2.2.3 Postage Value Download Status Message 

To acknowledge the success or failure of the processing of the postage value download 
message, the PSD shall create a status message for transmission to the USPS. 

3.2.2*3.1 Postage Value Download Status Message Format 

The status message shall contain the fields, sizes, and formats that are indicated in Table 
3.2-3. However, the size of the digital signature and the PSD X.509 certificate fields may 
vary if the vendor implements another USPS-approved digital signature approach. 

Table 3.2-3. Postage Value Download Status Message Format 



JField Name 


Size 


/Comments ,^ 


j Device ID/Type 


7 bytes 


The requesting PSD's Device ED/Tvpe number 


H Transaction ID 


3 bytes 


The same Transaction ID included in the original PVD 
request message and returned in the PVD message 


Status 


1 bvte 


Applicable status numbers are TBD 


Date/Time 


5 bytes 


The date and time the PSD completed the postage value 
download or encountered any errors 


Digital Signature 


DSA 

40 
bytes 


RSA 
128 
bytes 


The digital signature will be used to verify that the message | 
was not altered enroute to the USPS. For DSA, the first 20 I 
bytes of this field will contain the r* value. The last 20 bytes | 
will contain the s* value. 


PSD X.509 Certificate 


DSA 
235 
bvtes 


RSA 
323 
bvtes 


The X.509 Certificate containing the public key necessary to 
verify the digital signature. 



3.2.2.3.2 Postage Value Download Status Message Signature Generation 

The digital signature for the postage value download status message shall be created by 
the PSD as specified in Section 3.1.1 of this specification. If the PSD implements DSA, 
the input message for the digital signature process is shown in Figure 3 .2-6. If the PSD 
implements RSA, the digital signature input message is shown in Figure 3.2-7 . 
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Figure 3.2-6. DSA Input for PVD Status Message Signature Generation 



Device ID/Type 


Transaction ID 


Status 


Date/Time 


Message Pad 


7 Bytes 


3 Byte* 


1 Byte 


5 Byte* 


48 Bytes 



t 



Mo it 

Significant 
Biiof Most 
Significant 
Byte of Device 
ID/Type 



Most 

Significant 
Bit of Most 
Significant 
Byte of 
Transaction ID 
Field 



t t t 



Most 
Significant 



Most 
Significant 



Bit of Most Bit of Most 

Significant S igiuficanl 

Byte of Byte of 

Sums Field Date/Tune Field 



First Bit of 
Message Pad 
In Accordance 
With FTPS PUB 
180-1 



Note: 

I. The contents of the Device ID Hype. Transaction Number, and Status fields will be binary representations of each numeric 
digit with two digits in each byte 



Figure 3.2-7. RSA Input for PVD Status Message Signature Generation 



Device ID/Type 


Transaction ID 


Status 


Date/Time 


7 Bytes 


3 Bytes 


I Byte 


5 Byte* 



t 



Moat 

Significant 
Bit of Moat 
Significant 
Byte of Device 
ID/Type 



t 



Most 

Significant 
Bit of Most 
Significant 
Byte of 
Transaction ID 
Field 



t t 



Most 

Significant 
Bit of Most 
Significant 
Byte of 
Status Field 



Most 

Significant 
Bit of Moat 
Significant 
Byte of 

Date/Time Field 



Note: 

1. The contents of die Device ID/Type, Transaction Number, and Sutus fields will be binary represenutiom of each numeric 
digit with two digits in each byte. 



3.2.2.4 Postage Value Download Device Audit Message 

Subsequent to the processing of the postage value download message and the creation of 
the status message, the PSD shall generate a device audit message as specified in Section 
3.2.4. 
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3.2.2.5 Postage Value Download Error Message 



The IBIP infrastructure will return an error message to the PSD in response to a postage 
value download request message that fails validation, as discussed in this section. 

3.2.2.5.1 Postage Value Download Error Message Format 

The postage value download error message shall contain the fields, sizes, and formats ths 
are indicated in Table 3.2.4. However, the size of the digital signature field may vary if 
the vendor implements another USPS-approved digital signature approach. 



Table 3.2-4. Postage Value Download Error Message Format 



Field Name 



Device ID/Type 



Transaction ID 



Error Code 



Digital Signature 



Comments 



7bvtes 



3 bytes 



1 bvte 



PSA 

40 
bytes 



RSA 
128 
bytes 



The requesting PSD's device ID/tvpe number 



The transaction ID from the postage value download 
request message 



Applicable error codes are TBD 



The digital signature will be used to verify that the 
message was not altered enroute to the PSD. For DSA, the 
first 20 bytes of this field will contain the r' value and the 
last 20 bytes will contain the s' value. 



3,2.2,5.2 Postage Value Download Error Message Signature Verification 

Upon receipt of a postage value download error message from the host system, the PSD 
shall format the data for signature verification. If the PSD uses DSA or RSA, the data 
shall be formatted as shown in either Figure 3.2-8 or Figure 3.2-9 for input into the ^ 
signature verification process. If the PSD implements DSA, the PSD shall extract the r 
and s' values for the signature verification process from the digital signature field in the 
received postage value download message. 

The PSDs implementing either DSA or RSA shall use the signature verification process 
defined in Section 3.1.1 to verify that the message was received without modification. If 
the verification process fails, the message shall be discarded without further processing, 
and an appropriate error indication shall be returned to the host system. 
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Figure 3.2-8. Input for Postage Value Dow nload Error Message Signature 

Verification using DSA 



Device ID/Type 


Transaction ID 


Sutus 


_ Message Pad 


7 Bytes 


3 Byles 


1 Byte 


53 Bytes 



t 



t 



t t 



Moil 

Significant 
BU of Most 
Significant 
Byte of Device 
ID/Type 



Most 

Significant 
Bit of Most 
Significant 
Byte of 
Transaction ID 
Field 



Most 

Significant 
Bit of Most 
Significant 
Byte of 
Sutus Field 



Firet Bit of 
Message Pad 
In Accordance 
With FD>S PUB 
UO-I 



Note: r . 

I The contenta of the Device ID-Type. Transaction Number, and Sutus fields will be binary repreaenutions of each 
numeric digit with two digiu in each byte - 



Figure 3.2-9. Input for Postage Value Download Error Message Signature 

Verification using RSA 



Device ID/Type 


Transaction ID 


Status 


7 Byte. 


3Byu» 


1 Byte 



t t 



Moat 

Significant 
Bit of Moat 
Significant 
Byte of Device 
ID/Type 



Mob 
Significant 
Bit of Moat 
Significant 
Byte of 
Trmmacoon H) 
Field 



Mot 

Signifioant 
Bit of 
Sou Field 



The contenu of the D« ice ID/Type. Tramacoon Niamtwr, and Sutus fields wffl be binary reprwomationi of each 
numeric digit with two digits m each byte 



3.2.3 Indicium Creation Function 

| The role of the PSD in the IB IP indicium creation function is to perform security-critical 
l^rQcesses as described in this section. It is the responsibility of the host system i to 
"^ap propriately use the information provided by the PSD to cr eate t he indicium . It any of the 
processes described in this section fails the PSD shall issue an appropriate error message 
to the host system. 
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3.2.3.1 Indicium Creation Host Request 

The PSD shall accept a request from the host system to perform the security functions that 
are necessary for the host to create an indicium. The format of this request is at the 
discretion of the PSD vendor but shall consist minimally of the requested postage amount 
and the special purpose field, as defined in the D3EP Indicium Specification. 

3.2.3.2 Indicium Creation Register Operations 

The PSD shall perform the maximum and minimum limit checks and register operations in 
accordance with Section 3.1.2.2 of this specification before signing the register values. 

3.2.3.3 Indicium Creation Signature Generation 

The PSD shall generate a digital signature for the indicium as defined in the IB IP Indicium 
Specification and Section 3.1.1 of this specification. Additional digital signature methods 
may be used only with USPS approval. The criteria for the approval are defined in the 
IBEP Indicium Specification Section 4.4. 

3.2.3.4 Indicium Creation Results Output 

Upon successful completion of the processes defined in Sections 3.2.3.1 through 3.2.3.4, 
the PSD shall output the following fields to the host system: ascending register, 
descending register, and the digital signature. It will be the responsibility of the host 
system to generate the bar code portion of the indicium. 

3.2.4 Device Audit Function 

The primary role of the PSD in the device audit function is to create device audit messages 
and pass those messages to the host system for transmission to the USPS. The PSD shall 
initiate the device audit function upon host request and to request the reset of a "timed 
out" watchdog timer. The PSD also shall automatically create and send an audit message 
with the postage value download status message after processing a postage value 
download message. 

The overall device audit process is illustrated in Figure 3.2-10. Upon receipt of a device 
audit message other than one received as the final step in the postage value download 
process, the USPS IBEP infrastructure will create a device audit response message and 
return that message to the PSD. After validating the response message, the PSD shall 
reset the watchdog timer to its initial value. 
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Figure 3,2-10. Device Audit Process 
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3.2.4.1 Device Audit Message 

Device audit messages created by the PSD shall conform to the requirements contained in 
this section. 

3.2.4.1.1 Device Audit Message Contents 

The PSD shall create device audit messages that contain the fields, sizes, and formats 
indicated in Table 3.2-5, however the size of the digital signature and the PSD X.509 
certificate fields may vary if the vendor implements another USPS-approved digital 
signature approach. 

For device audit messages created as the final step in the postage value download process, 
the transaction ID from the postage value download message shall be used. For all other 
device audit messages, a unique transaction ID shall be generated. The PSD shall assign 
transaction ID numbers for device audit messages in a manner similar to that for postage 
value download request messages. 
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Table 3.2-5. Device Audit Message Format 



II ■ Field Name 


Size 


Comments 


Device ID/Type 


7 bvtes 


The originating PSD Device ID/Tvpe number 


Transaction ID 


3 bytes 


An identification number for this device audit message 


Ascending Register 


6 bvtes 


Value of the ascending register 


Descending Register 


5 bvtes 


Value of the descending register 


Audit Message Creation 
A Date/Time 


5 bytes 


Date and time the audit message was created in format 
YYMMDDHHMM 


| Previous Added Postage 
Value 


5 bytes 


Added Postage Value amount from the most recent postage I 
value download message i 


Previous Postage Value 
Download Date/Time 


5 bytes 


Date/time that the most recent postage value download | 
message was processed | 


Digital Signature 


PSA 

40 
bytes 


RSA 
128 
bytes 


The digital signature will be used to verify that the 
message was not altered enroute to the PSD. The first 20 
bytes of this field will contain the r' value and the last 20 
bvtes will contain the s' value 


PSD X.509 Certificate 


DSA 
235 
bvtes 


RSA 
323 
bvtes 


The X.509 Certificate containing the public key necessary 
to verify the digital signature 



3.2.4.1.2 Device Audit Message Signature Generation 

The PSD shall generate a digital signature for the device audit message as defined in 
Section 3.1.1 of this specification. If DSA is implemented, the input message for the 
signature generation function is shown in Figure 3.2-1 1. If RSA is implemented, the 
input message for the signature generation is shown in Figure 3.2-12. 
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Figure 3.2-11. DSA Input Format for Device Audit Signature Generation 
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Figure 3.2-12. RSA Input Format for Device Audit Signature Generation 
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3.2,4.2 Device Audit Response Message 

The IBIP infrastructure will return a device audit response message to the PSD in 
response to the receipt of a device audit message unless the device audit message was 
received as the final step in the postage value download process. The processing of the 
device audit response message by the PSD is specified in this section. 

3.2.4.2.1 Device Audit Response Message Format 

The device audit response message shall contain the fields and sizes indicated in Table 3.2- 
6, however the size of the digital signature field may vary depending on the digital 
signature method implemented by the PSD. 
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Table 3,2-6. Device Audit Response Message Format 



1 Field Name 


Size 


- : -j . — Comments | 


Device ID/Type 


7 bvtes 


The PSD's device ID/type number I 


Transaction ID 


3 bvtes 


The transaction ID from the device audit message 


Status Code 


1 bvte 


Applicable status codes are TBD j 


Digital Signature 


PSA 
40 


RSA 
128 


The digital signature will be used to verify thai the message 
was not altered enroute to the PSD. For DSA, the first 20 




bytes 


bytes 


bytes of this field will contain the r' value and the last 20 bytes 
will contain the s' value 



3.2.4.2.2 Device Audit Response Message Signature Verification 

Upon receipt of a device audit response message from the host system, the PSD shall 
format the data for signature verification. If the PSD uses DSA or RSA, the data shall be 
formatted as shown in either Figure 3.2-13 or Figure 3.2-14 for input into the signature 
verification process. If the PSD implements DSA, the PSD shall extract the r* and s' 
values for the signature verification process from the digital signature field in the received 
postage value download message. 

The PSDs implementing either DSA or RSA shall use the signature verification process 
that is defined in Section 3.1.1 to verify that the message was received without 
modification. If the verification process succeeds, the PSD shall reset its watchdog timer 
to its initial value. If the verification process fails, the PSD shall discard the device audit 
response message without further processing and shall return an appropriate error 
indication to the host system. 



Figure 3.2-13. Input for Device Audit Response Message Signature Validation 
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Figure 



3.2-14. RSA Input for Device Audit Response Message Signature Validation 
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4. PSD PHYSICAL REQUIREMENTS 



This section describes the physical requirements to which PSD shall conform. It is not the 
intent of this specification to require a particular physical form factor. The requirements 
presented in this section are those necessary to ensure the integrity of the PSD and the 
IB IP system. 

4.1 PSD Security 

The PSD shall be designed and implemented in accordance with FIPS PUB 140-1 The 
PSD shall conform to the requirements for security level 3 or as defined in Table 4.1-1. 



Table 4.1-1. FTPS PUB 140-1 Requirements Applicable to PSD 



FIPS 140-1 
Design Category 


Proposed PSD Specification / 
FIPS 140-1 Requirements 


Comment y- 


1 Crypto Module 


Documentation Required: 

• PSD Module Description (by vendor) 

• Specification of PSD cryptographic module 
and its cryptographic boundary (by vendor) 

• PSD security policv (bv vendor) 


Vendor PSD description and 
specmcauon must compij wim 
this PSD Specification; vendor 
PSD security policy must comply 
with IBIP Security Policy 


iViOULUC 1X1 1 CI Idwwo 


Paih« eimlieitlv defined CHx vendorV 

power and control paths (from host system) 

input data (through host system) 

separate inputs for data and plaintext security 

parameters (keys and access control data), or 

single input if security parameters are protected 

output data and status (to host system) 

optional; maintenance access (vendor proprietary) 


Message and data formats are to 
comply with the definitions in 
this PSD Specification 


Roles 


Authorized roles 

• User (customer through host system) 

• Crypto officer (vendor) 

• Maintenance (vendor-required if optional 
maintenance port is implemented) 

Access control - authentication by role for user, 
vendor, or individual (optional) 


Minimum access control shall 1 
satisfy security level 2 (role- 
based) access; security level 3 
and 4 (individual) access is 
optional; at least a PIN/password 
entry is needed for either case. 


Services 


• Initiate and run self-tests 

• Output module status to host system 

• Output module alarms to host system 

• Accept host system controls 

• PSD core and IBTP functions 

• No bypass capability 


Self-tests - see below- 


U Finite State Machine 
1 Model 


Comply with FTPS PUB 140-1, section 4.4 design 
and documentation requirements 


Required documentation from 
vendor/manufacturer 


| Physical Security 


Table 4.6-1, PSD Physical Security requirements 




0 Environmental 

1 Failure Protection or 
I Testing (EFP/EFT) 


Employ environmental failure protection features 
or undergo environmental failure protection testing 
for accreditation 


Implemented to counter a 
potential tampering mode 
(especially voltage and 
temperature) | 
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TIPS 14<*-1 
Design Category 


— Proposed PSD Specification / 1 
TIPS 140-1 Acquirements 


"»# torn men t" *v* ~ 


HSoiTw'are Security 


Required documentation: software design, 

relationship of design to security policy, and 

annotated complete source code 

Implement in high level language unless low level 

language essential or high level language not 

available 


Additional documentation 
required from vendor/ 
manufacturer 


Operating System 
Security 


Not applicable m 


Required only if operator has 
means of loading device software 


Key Management 


• Key generation - Only internal generation of 
PSD's public and private keys 

• Key distribution - Public key distribution TBD 

• Key archiving - PSD public key sent to USPS 
upon generation/loading 


No key extraction except PSD 
public key 


Crypto Algorithms 


Implement either DSS, RSA, or other USPS 
approved signature generation and^yerification 
algorithm 


Vendor may need to obtain 
necessary rights to use 


Electromagnetic 
Interference and 
Compatibility 
(EMI/EMC) 


Comply with EMI/EMC requirements specified by 
FCC Part 15, Subpart J, Class B (i.e., for home 
use, conforms to security levels 3 and 4) 


Primarily for compatibility with 
other electronic devices 


Self-Tests 


Statistical random number generator test 
performed during initialization and again at 
authorization. 
Power up self-tests: 

• Crypto algorithm (known answer) 

• Error detection code or authentication 

• Critical functions 

Conditional tests: TBD by vendor (pair-wise 
consistency, software/firmware load, manual key 
entrv, continuous random number generator) 


Testing must ensure proper I 
operation of PSD functions 



4.2 PSD Contents 

The PSD shall include an FIPS 140-1 compliant random number generator. 
The PSD shall include a real-time clock. 

The PSD shall include a backup battery capable of maintaining the real-time clock and 
tamper detection/response circuitry for a minimum of five years from installation. Other 
means of ensuring the retention of anti-tamper functions, PSD data, and continued 
operation of the real-time clock in the absence of primary input power, which is in lieu of a 
battery, will be evaluated, if proposed. 

The PSD shall output an alarm signal indication in the event of a low battery power level 
condition. 



Information Based Indicia Program (IBIP) June l3 * 1996 

PSD Specification: Draft Document 



4-2 



BNSDOCID: <XP 2137734A_I_> 



4.3 PSD Internal Storage ! • f\ ; *\ t : ' \, : \. 

PSD internal storage shall satisfy the data requirements of Sections 3 . 1 and 3 .2 of this 
specification. Table 4.3-1 lists the minimum data required by EBIP in nonvolatile storage. 



Table 4.3-1, PSD Internal Storage 



|l Item 


Size . . ; 1 


Device ID/Type 


7 bvtes 


License ID 


5 bytes 


PSD Private Key 


160 bits for DSA or 1024 bits for RSA 


IB IP Common Parameters 


TBD 


Originating Address 


11 digits 


Maximum/Minimum Postage 


2.5 bytes each 


Values 


Ascending Register 


12 digits 


Descending Register 


9 digits 


Transaction ID 


3 bytes 


PSD X.509 Certificate 


TBD 


Vendor X.509 Certificate 


TBD 


USPS X.509 Certificate 


TBD 



4.4 PSD Software 

The PSD shall comply with the FIPS PUB 140-1 software security requirements 
appropriate for its security level. 

The PSD shall comply with the operating system requirements applicable in accordance 
with FIPS PUB 140-1. 

If the PSD vendor chooses a remote method of modifying software in the PSD, the change 
message will require a signature verification by the PSD before the software is updated. 

4.5 Watchdog Timer 

The initial value of the watchdog timer shall be set by the vendor at authorization. The 
watchdog timer shall be tied to the real-time clock in the PSD. When the timer expires, 
the PSD shall be unable to create additional indicia. A PSD that is disabled shall be reset 
only upon receipt of a valid device audit response message as discussed in section 3 .2.4 of 
this specification. A PSD that is disabled will retain its memory and not zeroize, but it 
cannot be used to create indicia until the device audit response message is received. 
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4.6 PSD Tamper Resistance • • ••• ' 

The PSD shall have an explicitly defined perimeter that establishes the physical bounds of 
the cryptographic module and the cryptographic boundary, including the processor for the 
software and/or firmware that executes the code. The requirements for different format 
options are summarized in Table 4.6-1. 



Table 4.6-1, PSD Physical Security Requirements (per FTPS PUB 140-1) 



Single Chip Module 
(stand-alone or embedded) 


Multi-Chip 
Module 


Multi-Chip Stand-Alone 
Module 


Inherently tamper resistant 'y2L 

€C 9 CTTlTirt £strd\ 


ICs with interconnections, not within a 

pi UmflMi CIIWIl/3UJb lb.IL. bApolUIUll 

boards/adapters) 


ICs interconnected within orotected 

enc IrtOtni* : o nrinfwt fimiif 

vUWIUfUlv Iw. fC. . 1 w UJ lUlbU WIWUll 

board or ceramic substrate) 


• Hard opaque removal 
resistant coating including 
or covering passivation 

• Tamper response and 
zeroization active when 
keyed 

r Include environmental 
failure protection 
(shutdown or zeroizau'on, 
especially for temperature 
and voltage), or undergo 
environmental failure 
testing 


• Strong non-removable enclosure 

• Completely within tamper 
detection envelope 

• Tamper response and zeroizau'on 
circuitry' active when keyed 

• Any ventilation holes/slits to 
include anti probe design (e.g., 90 
degree bends) completely witl j 
tamper detection envelope. 

» Include environmental failure 
protection (shutdown or 
zeroization, especially for 
temperature and voltage), or 
undergo environmental failure 
testing 


• Strong removal-resistant enclo- 
sure, with tamper detection for 
entire envelope 

• Tamper response and zeroization 
circuitry active when keyed 

• Any ventilation holes/slits to 
include anti probe design (e.g., 
90 degree bends) 

• Include environmental failure 
protection (shutdown or 
zeroization, especially for 
temperature and voltage), or 
undergo environment*] failure 
testing 



The PSD shall use tamper detection countermeasures that respond to tampering by 
disabling the PSD from further use until completion of a physical inspection by USPS. The 
PSD ascending and descending register values shall be retained at the values that were 
present when the tampering was detected. 



The PSD shall not provide any capability to bypass the security services of the 
cryptographic module. 

4.7 PSD Access Control 

The PSD shall employ security mechanisms to restrict unauthorized physical access to the 
contents of the module, thereby deterring unauthorized use and unauthorized modification 
(including substitution) of the PSD. 

The PSD shall directly or through the host system authenticate any person who is 
authorized to perform the role of operator of the PSD (FIPS PUB 140-1, Security Level 2 
minimum requirement e.g., password or PIN). 
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4.8 PSD Key Handling 

PSD key entry and output, distribution, and storage shall be in accordance with the IBIP 
System Specification, Appendix (TBD), PSD Key Management. 

PSD keys shall be stored in plaintext form in the cryptographic module and shall not be 
accessible from outside the device. 

The PSD shall include a mechanism to ensure that stored keys shall remain associated with 
the correct device ID. 

The PSD shall provide the capability to zeroize all plaintext cryptographic keys and other 
unprotected security parameters within the module. 

The PSD shalt not output its private keys. 
4.9 PSD Input and Output Requirements 

The data ports for unencrypted, critical PUD-security parameters shall be physically 
separated from other data ports. 

If plaintext authentication data (e.g., password or PIN) is used, the entry port shall be 
physically separate from any other cryptographic module data entry port and allow for 
direct entry of the data. 

The PSD shall provide an output for indication of the status of the device. 
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5. PSD TESTING RE^UrkEI^ENTS ' ' . . . ' \ / ' . : 

This section describes the testing requirements for the PSD. 

The PSD shall be tested for conformance with FIPS PUB 140-1 through the 
Cryptographic Module Validation Program by a cryptographic module testing laboratory 
that is a member of an accredited National Voluntary Laboratory Accreditation Program 
and shall receive a validation certificate. In addition, the PSD shall be evaluated by the 
USPS and receive IBIP accreditation. 

The PSD shall either employ environmental failure protection features or undergo 
environmental testing, as required by HPS PUB 1 40- 1, to the extent appropriate for its 
security level. 

Upon authorization for service to a customer, the PSD shall be tested for proper time 
stamping, signature generation, indicium data creation and output, signature validation, 
and maintenance of required data in its data storage registers. 

The PSD shall initiate and run self-tests to ensure proper operation in accordance with 
FIPS PUB 140-1. ~ 
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APPENDIX A: LIST OF ACRONYMS \." 
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ANSI American National Standards Institute 

DMM Domestic Mail Manual 

DSA Digital Signature Algorithm 

DSS Digital Signature Standard 

IB LP Information Based Indicia Program 

NIST National Institute of Standards and Technology 

PKCS Public Key Cryptographic Standards 

PSD Postal Security Device 

SHA Secure Hash Algorithm 

USPS United States Postal Service 
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